feat: add clock_ticker for apps that only need the tick count - #646

I guess as a work-around one could still subscribe to clock events and use a global variable to share the count to the other loops. Now we just need to decide if that's how we want this case to be handled @chmanie .

For context PR #644 was meant to bring back the ticker for apps that do not use the clock events:

App::clock_ticker() hands an app a plain fn() -> u64 that reads the current 24 PPQN tick out of TICK_COUNTER. Apps that derive everything from the tick number and never react to Start/Stop/Reset can use it instead of use_clock(): it costs no CLOCK_PUBSUB subscriber slot, and an app that falls behind cannot back up the shared clock queue. u64::MAX means “not started”; the counter going backwards means the clock was restarted or reset.

It is #[allow(dead_code)] on main — the first users are the WIP app branches, where a clocked app that also awaits a MAX write or a MIDI send inside its loop is exactly the subscriber that used to stall the gatekeeper.

Stacked on https://github.com/ATOVproject/faderpunk/pull/638 (which is itself stacked on https://github.com/ATOVproject/faderpunk/pull/636), because TICK_COUNTER is introduced there. Cross-repo PRs can only target main, so this diff shows all three commits; merge https://github.com/ATOVproject/faderpunk/pull/636 and https://github.com/ATOVproject/faderpunk/pull/638 first and it shrinks to the app.rs change alone.

No test checklist: this adds an unused accessor and changes no behaviour on its own.

Opened by an AI coding agent on @kosmar's behalf.```

Following up after reviewing #636/#638: this PR's App::clock_ticker() depends entirely on TICK_COUNTER, which no longer exists — #638 replaced it with METRONOME_SIGNAL (an embassy_sync::Signal), since that's a better fit for its actual single-consumer use case (the metronome) and avoids an always-on 1ms poll. So this PR can't be rebased onto the current stack as-is; it needs a rewrite, not just a merge.

Beyond that, holding off on this makes sense independent of the rebase issue: there's currently no app in main calling clock_ticker() (it ships #[allow(dead_code)]), so merging it now would be unused public API ahead of a real consumer. Recommendation: for now, WIP apps that only need the tick count should use the app-level workaround (a local atomic fed from ClockEvent::Tick, same shape this PR was formalizing) rather than wait on this.

If/when a real app needs this for real, worth reconsidering embassy_sync::watch::Watch instead of a bare atomic at that point — it's already the codebase's established "shared state, multiple independent readers" primitive (same family as LAYOUT_WATCH/GLOBAL_CONFIG_WATCH), and unlike a single-consumer Signal it cleanly supports several apps polling independently, which is probably the actual shape needed here. Leaving this open for now rather than closing, in case that's useful reference when we get there.

you can use a loop like this until we revisit this:

    loop {
        match clk.wait_for_event(ClockDivision::_1).await {
            ClockEvent::Tick(tick) => {
                glob_ticks.set(tick);
            }
            _ => {}
        }
    }
};

Thanks — we'll use the drain-loop workaround on the WIP apps (dedicated wait_for_event task that only stores the absolute tick; the rest of the app may park on MAX/MIDI). No rush on Watch / clock_ticker until something on main actually needs it.

Written by an AI coding agent on @kosmar's behalf.